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Abstract. Applicative functors define an interface to computation that 
is more general, and correspondingly weaker, than that of monads. First 
used in parser libraries, they are now seeing a wide range of applications. 
This paper sets out to explore the space of non-monadic applicative func- 
tors useful in programming. We work with a generalization, lax monoidal 
functors, and consider several methods of constructing useful functors 
of this type, just as transformers are used to construct computational 
monads. For example, coends, familiar to functional programmers as ex- 
istential types, yield a range of useful applicative functors, including left 
Kan extensions. Other constructions are final fixed points, a limited sum 
construction, and a generalization of the semi-direct product of monoids. 
Implementations in Haskell are included where possible. 

1 Introduction 

This paper is part of a tradition of applying elementary category theory to the 
design of program libraries. Moggi [16] showed that the notion of monad could be 
used to structure denotational descriptions of programming languages, an idea 
carried over to program libraries by Wadlcr [20]. It turns out that the monads 
useful in semantics and programming can be constructed from a small number 
of monad transformers also identified by Moggi [17]. 

Applicative functors [15] provide a more limited interface than monads, but 
in return have more instances. All monads give rise to applicative functors, 
but our aim is to explore the space of additional instances with applications 
to programming. We are particularly interested in general constructions, with 
which programmers can build their own applicative functors, knowing that they 
satisfy the required laws. It is already known that applicative functors, unlike 
monads, can be freely composed. We identify a number of further general con- 
structions, namely final fixed points, a limited sum construction, a generalization 
of semi-direct products of monoids, and coends (including left Kan extensions). 
By combining these constructions, one can obtain most of the computational 
applicative functors in the literature, with proofs of their laws. General con- 
structions also clarify the relationships between seemingly unrelated examples, 
and suggest further applications. 

Elementary category theory provides an appropriately abstract setting for the 
level of generality we seek. An idealized functional language corresponds to a type 
of category with first-class functions (a cartesian closed category). Applicative 
functors on such a category are equivalent to a simpler form called lax monoidal 
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functors, which are more convenient to work with. We can build up lax monoidal 
functors in more general ways by ranging across several different categories, as 
long as the end result acts on the category of our functional language, and is 
thus applicative. Familiarity with the basic definitions of categories and functors 
is assumed. The other notions used are mostly shallow, and will be explained 
along the way. 

In the next section, we introduce applicative and lax monoidal functors. The 
rest of the paper describes the general constructions, illustrated with examples in 
Haskell where possible. Two proof styles are used throughout the paper. When 
making statements that apply to any category, we use standard commuting 
diagrams. However many statements assume a cartesian closed category, or at 
least a category with products. For these we use the internal language of the 
category, which provides a term language with equational reasoning that will be 
familiar to functional programmers. 

2 Applicative Functors 

The categorical notion of "functor" is modelled in Haskell with the type class 

class Functor f where 

fmap : : (a -> b) -> f a -> f b 

Instances include a variety of computational concepts, including containers, in 
which fmap modifies elements while preserving shape. Another class of instances 
are "notions of computation" , including both monads and applicative functors, 
in which terms of type F a correspond to computations producing values of type 
a, but also having an "effect" described by the functor F, e.g. modifying a state, 
possibly throwing an exception, or non-determinism. The requirement that F be 
a functor allows one to modify the value returned without changing the effect. 

The applicative interface adds pure computations (having no effect) and an 
operation to sequence computations, combining their results. It is described by 
a type class: 

class Functor f => Applicative f where 
pure : : a -> f a 

(<*>) : : f (a -> b) -> f a -> f b 

If we compare this with the type class of monads: 

class Monad m where 

return : : a -> m a 

(»=) : : m a -> (a -> m b) -> m b 

we see that pure corresponds to return; the difference lies in the sequencing 
operations. The more powerful »= operation available with monads allows the 
choice of the second computation to depend on the result of the first, while in 
the applicative case there can be no such dependency. Every monad can be made 
an applicative functor in a uniform way, here illustrated with the Maybe monad: 



Constructing Applicative Functors 3 



instance Functor Maybe where 

fmap f m = m »= \ x -> return (f x) 

instance Applicative Maybe where 
pure = return 

mf <*> mx = mf >>= \ f -> mx >>= \ x -> return (f x) 

For functors that are also monads the monadic interface is often more convenient, 
but here we shall be more interested in applicative functors that are not also 
monads. A simple example is a constant functor returning a monoid [15]. Here 
is that functor expressed in Haskell using the Monoid class, which defines an 
associative binary operation <> with identity mempty: 

newtype Constant a b = Constant a 

instance Functor (Constant a) where 
fmap f (Constant x) = Constant x 

instance Monoid a => Applicative (Constant a) where 
pure _ = Constant mempty 

Constant x <*> Constant y = Constant (x <> y) 

The more limited applicative interface has many more instances, some of which 
will be presented in later sections. For example, the constrained form of sequenc- 
ing offered by the applicative interface makes possible instances in which part 
of the value is independent of the results of computations, e.g. parsers that pre- 
generate parse tables [18]. Unlike monads, applicative functors are closed under 
composition. 

However many applications of monads, such as traversal of containers, can 
be generalized to the applicative interface [15]. 

2.1 Lax Monoidal Functors 

The applicative interface is convenient for programming, but in order to explore 
relationships between functors we shall use an alternative form with a more 
symmetrical sequencing operation: 

class Functor f => Monoidal f where 
unit : : f 0 

mult : : f a -> f b -> f (a, b) 

This interface, with identity and associativity laws, is equivalent to the applica- 
tive interface — the operations are interdefmable: 

pure x = fmap (const x) unit 

a <*> b = fmap (uncurry id) (mult a b) 

unit = pure () 

mult a b = fmap (,) a <*> b 
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If we uncurry the operation mult of the Monoidal class, we obtain an oper- 
ation © : F a x F b — »■ F (a x b). This suggests generalizing from products to 
other binary type constructors, a notion known in category theory as a monoidal 
category. 

A monoidal category [13] consists of a category C, a functor ®:CxC^C 
and an object T of C, with coherent natural isomorphisms 

A : T © a = a (left identity) 

p : a © T = a (right identity) 

a : a © (6 © c) = (a © b) © c (associativity) 

A symmetric monoidal category also has 

cr:a©6 = &©a (symmetry) 

Both products and coproducts are examples of monoidal structures, and both 
are also symmetric. Given a monoidal category (C, T, ©, A, p, a), the category 
C op , obtained by reversing all the morphisms of C, also has a monoidal struc- 



ture: (C op ,T,©, A _1 ,p- 



The product of two monoidal categories is also 



monoidal, combining the isomorphisms of the two categories in parallel. 

Often we simply refer to the category when the monoidal structure is clear 
from the context. 

Some functors preserve this structure exactly, with T' — FT and F a®' F b — 
F (a © b); a trivial example is the identity functor. Others, such as the product 
functor x : A x A — > A preserve it up to isomorphism: 

1 = 1x1 

(ai x a 2 ) x (&! x b 2 ) = (ai x bi) x (a 2 x b 2 ) 

We obtain a larger and more useful class of functors by relaxing further, requiring 
only morphisms between the objects in each pair, thus generalizing the class 
Monoidal above from products to any monoidal category. 

A lax monoidal functor between monoidal categories (C, <X>, T) and (C , <X>', T') 
consists of a functor F : C — > C with natural transformations 

u:T'->FT (unit) 

© : F a <g/ F b -> F {a ® 6) (multiplication) 

such that the following diagrams commute: 



Ttxi-Fa- 

ulglF a 

¥ 

FT © Fa ■ 



Fa 

FA 



F (T © a) 



Fa © T - 

F a®u 

{ 

Fa © FT 



Fa 

A 

Fp 



F (a © T) 



Fa(g> (Fb(g> Fc) 



(Fa®Fb)(g>Fc- 



©«)Fc 



F(a8i)8Fc- 



■F(a© (&©c)) 



Fa 



■F((a©&)©c) 
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The first two diagrams state that u is the left and right identity respectively of 
the binary operation ©, while the last diagram expresses the associativity of ©. 



2.2 Weak Commutativity 



Although the definition of a lax monoidal functor neatly generalizes the Monoidal 
class, it lacks the counterpart of pure. We will also want an associated axiom stat- 
ing that pure computations can be commuted with other computations. (There 
is a notion of symmetric lax monoidal functor, but requiring the ability to swap 
any two computations would exclude too many functors useful in computation, 
where the order in which effects occur is often significant.) 

Thus we define an applicative functor on a symmetric monoidal category C 
as consisting of a lax monoidal functor F : C — > C, with a natural transformation 
p : a — > F a (corresponding to the pure function of the Applicative class) 
satisfying p T — u and po® = ®op®p, plus a weak commutativity condition: 



a®Fb — — ^Fa<g)Fb 



Fb®a- 



Fb®p 



Fb®Fa 



■F{a®b) 

Fa 

■ 

■ F (b <g> a) 



We could also express the weak commutativity condition as a constraint on 
functors with a tensorial strength, but here we shall avoid such technicalities by 
assuming that function spaces are first-class types, with primitives to perform 
application and currying, or in categorical terms that we are working in a carte- 
sian closed category (ccc). In particular, if 4 is a ccc, any lax monoidal functor 
F : A — > 4 is also applicative. To show this, we make use of another advantage 
of working in a ccc, namely that we can conduct proofs in the internal A-calculus 
of the category [12], in which variables of type a stand for arrows of .4(1, a), and 
we write / (ei, . . . , e n ) for / o (ei, . . . , e n ). The result is a convenient language 
that is already familiar to functional programmers. When working in categories 
with products we shall calculate using the internal language; when products are 
not assumed we shall use diagrams. 

In the internal language, we can define p : I F with the counterpart of 
the above definition of pure for any Monoidal functor: 



px = F (const x) u 
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The proof of weak commutativity is then a simple calculation in the internal 
language: 



F a(px ®y) — Fa(F ( const x)u®y) definition of p 

= F (a o [const x) x id) (u ® y) naturality of © 

= F (a o (const x) x id) (F A -1 y) left identity 

= F (id x (const x) o a) (F A -1 y) naturality of a 

= F (id x (const x) o a o A -1 ) y functor 

= F (id x (const x) o p~ 1 )y symmetry 

— F (id x const x) (F p^ 1 y) functor 

= F (id x const x) (y © u) right identity 

= y © F (const x) u naturality of © 

— y ®px definition of p 



It is also known that lax monoidal functors in a ccc are equivalent to closed func- 
tors [5], which resemble the Applicative interface, but again the lax monoidal 
form is more convenient for defining derived functors. 

Thus our strategy will be to construct a lax monoidal functor over the product 
structure of a ccc, but we may construct it from constituents involving other 
monoidal categories. As a simple example, we have seen that the product functor 
x : A x A — > A is lax monoidal, and we can compose it with the diagonal functor 
from A to Ax A (also lax monoidal) to obtain a lax monoidal functor from A 
to A: 

Fa — a x a 

though in this case the resulting functor is also monadic. In Section 5 we also 
use auxiliary categories with monoidal structures other than products. 



3 Fixed Points, Limits and Colimits 



A standard example of a computational monad is the list monad, which may 
be used to model backtracking. There is another lax monoidal functor on lists, 
with a unit constructing infinite lists and multiplication forming the zip of two 
lists [15]: 

data ZipList a = Nil I Cons a (ZipList a) 



instance Functor ZipList where 
fmap f Nil = Nil 

fmap f (Cons x xs) = Cons (f x) (fmap f xs) 



instance Monoidal ZipList where 
unit = Cons () unit 

mult (Cons x xs) (Cons y ys) = Cons (x,y) (mult xs ys) 
mult = Nil 



Constructing Applicative Functors 7 



It turns out that this instance, and the proof that it satisfies the lax monoidal 
laws, follow from a general construction. We can observe that ZipList is a fixed 
point through the second argument of the binary functor F(a, b) = 1 + a x b. 
That is, F is the functor Maybe o x , a composition of two lax monoidal functors 
and therefore lax monoidal. 

There are two canonical notions of the fixed point of a functor, the initial and 
final fixed points, also known as data and codata. Initial fixed points can be used 
to define monads; here we use final fixed points to define lax monoidal functors. 
Recall that a parameterized final fixed point of a functor F : Ax B — > B consists 
of a functor vF : A — > B with an isomorphism c : F (a, vF a) = vF a and an 
unfold operator [(•)] constructing the unique morphism satisfying 



[(/)] 



vFa 

A 



If F is lax monoidal, we can define the unit and multiplication morphisms of a 
lax monoidal structure on vF as two of these unfolds: 



T- 



u vF = \u F \ 



vFT 



F (T, T) s- F (T, vF) 



vF ai <£> vF o 2 > vF [a\ ® a-i) 



F '(ai,vF ax) ® F {a 2 ,vF a 2 ) 

®F 

F (ai (3 a 2 ,vF ai® vF 0,2) *- F (ai (8) o 2 , (ai (8) a 2 )) 

_F (oi(8io2,©^f) 

In particular, for F = Maybe o x , this construction yields a lax monoidal functor 
equivalent to ZipList above. 

One can prove using fusion that this definition does indeed satisfy the lax 
monoidal laws, but we shall prove a more general result instead. 



3.1 Limits 



Ignoring the parameter A for the moment, another way to define the final fixed 
point of a functor F : B — > B starts with the terminal object 1. Using with the 
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unique morphism !^ 1 : F 1 — ► 1, we can define a chain of objects and morphisms: 
^ F 3 1 > F 2 1 > F 1 > 1 

F 2 ! F1 F\ F i I pi 

The final fixed point ^ F is defined as the limit of this chain, an object with a 
commuting family of morphisms (a cone) to the objects of the chain: 




such that any other such cone, say from an object B, can be expressed as a 
composition of a unique morphism B — > vF and the cone from vF. 

This construction is sufficient for final fixed points of regular functors like 
ZipList, but for the general case we need to lift the whole thing to the category 
Fun(_4, B), whose objects are functors A — > B, and whose morphisms are natural 
transformations. Given a functor <& on this category, we can repeat the above 
construction in the functor category, starting with the constant functor T: 




A standard result holds that limits in Fun(_4, B) may be constructed from point- 
wise limits in B [13, p. 112]. 

On the way to defining the final fixed point of <P as a lax monoidal func- 
tor, we wish to require that # preserve lax monoidal functors. To state this, 
we need a specialized notion of natural transformation for lax monoidal func- 
tors: a monoidal transformation between lax monoidal functors (F, ©, T) and 
(F',®',T') is a natural transformation h : F F' that preserves the lax 
monoidal operations: 




FT 



Fa®Fb^^F' a®F'b 



■F'T 



© 

F (a <g> b) 



©' 

I 

■ F' (a ® b) 



Then given monoidal categories A and B, we can define a category Mon(_4, B) 
with lax monoidal functors as objects and monoidal transformations between 
them as morphisms. Now suppose we have a diagram in Mon(^4, B), e.g. the 
chain 

> F 3 F 2 F 1 F Q 



h 



fo 
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We can construct a limit in Fun(A,B) (from pointwise limits in B): 
F. 




To extend F to a limit of this diagram in Mon(_4, B), we want to define opera- 
tions u and © on F such that the U are monoidal transformations, i.e. satisfying 
the following equations in B: 



T 



u / 

/ 




FT 



■ Ft T 



Fa®Fb- 
i 

© I 
Y 

F{a®b)- 



-^F t a®F t b 
F l (a <g> 6) 



These equations imply that u and © are mediating morphisms to the limits 
in B, and thus uniquely define them. It remains to show that © is a natural 
transformation, and that u and © satisfy the identity and associativity laws. Each 
of these four equations is proven in the same way: we show that the two sides 
of the equation are equalized by each ti, as a consequence of the corresponding 
equation on F i: and thus, by universality, must be equal. For example, for the 
left identity law we have the diagram 



T®Fa- 



M(g>F a 



FT ® F a- 




T <g> Fi a ■ 

Ui^)Fi a 



F t a 

A 

Fi X 



F,T®F t a -£->■ Fi (T ® a) 



FX 



F (T ® a) 



The central panel is the left identity law for Fi, while the four surrounding panels 
follow from the definitions of u and © and the naturality of A and U . Thus the 
two morphisms T <E) F a — > F a on the perimeter of the diagram is equalized by 
ti. Since the universality of the limit implies that such a morphism is unique, 
they must be equal. We have proven: 

Proposition 1. If B is complete, then so is Mon(_4, B). 

Applying this to the chain of the fixed point construction, we have the im- 
mediate corollary that the final fixed point of a higher-order functor <P on lax 
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monoidal functors is a uniquely determined extension of the final fixed point 
of <P on ordinary functors. For example, ZipList is the final fixed point of the 
higher-order functor <P is defined by <P Z a = Maybe (ax Z a). 

3.2 Sums 

The dual notion, colimits, is not as easily handled. We can construct sums in 
special cases, such as adding the identity functor to another lax monoidal functor: 

data Lift f a = Return a I Others (f a) 

instance Functor f => Functor (Lift f) where 
fmap f (Return x) = Return (f x) 
fmap f (Others m) = Others (fmap f m) 

instance Monoidal f => Monoidal (Lift f) where 
unit = Return () 

mult (Return x) (Return y) = Return (x, y) 
mult (Return x) (Others my) = Others (fmap ((,) x) my) 
mult (Others mx) (Return y) = Others (fmap (flip (,) y) mx) 
mult (Others mx) (Others my) = Others (mult mx my) 

Here pure computations (represented by the identity functor and the constructor 
Return) may be combined with mult, but are converted to the other functor if 
either computation involves that functor. 

Applying this construction to the constant functor yields a form of compu- 
tations with exceptions that collects errors instead of failing at the first error [4, 
15]: 

type Except err a = Lift (Constant err) a 

That is, in a computation mult el e2, after a failure in el, the whole computa- 
tion will fail, but not before executing e2 in case it produces errors that should 
be reported together with those produced by el. 

The fixed point L = Lift (/ x L) expands to non-empty lists combined with 
a "long zip", in which the shorter list is padded with copies of its last element 
to pair with the remaining elements of the longer list, as suggested by Jeremy 
Gibbons and Richard Bird 1 : 

data PadList a = Final a I NonFinal a (PadList a) 

instance Functor PadList where 

fmap f (Final x) = Final (f x) 

fmap f (NonFinal x xs) = NonFinal (f x) (fmap f xs) 



1 Personal communication, 5 July 2011. 
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instance Monoidal PadList where 
unit = Final () 

mult (Final x) (Final y) = Final (x, y) 
mult (Final x) (NonFinal y ys) = 

NonFinal (x, y) (fmap ((,) x) ys) 
mult (NonFinal x xs) (Final y) = 

NonFinal (x, y) (fmap (flip (,) y) xs) 
mult (NonFinal x xs) (NonFinal y ys) = 

NonFinal (x, y) (mult xs ys) 

A straightforward generalization is L = Lift (/ x (F o L)) for any lax monoidal 
F, defining forms of long zip for various kinds of tree. 

The Lift construction is able to combine computations in the identity func- 
tor with those of another lax monoidal functor F because there is a monoidal 
transformation between the two, namely the arrow pure. We can generalize: 

Proposition 2. If J is an upper semi-lattice and B is a ccc with finite coprod- 
ucts, a diagram A : J — > Mon(_4, B) has a colimit. 

Proof. Define a functor F by 

Fa=J2C j (A j a) 

Ff(C j x) = C j (fx) 

where the Cj : Aj -4 F are tagging injections (constructors) marking the terms 
of the sum. Then we can define a lax monoidal structure on F as follows: 

u = C± u± 
Cj a © Ck b — Cjuk (Aj<juk a, Ak<juk b) 

Naturality of © and the identity and associativity laws follow from simple cal- 
culations. □ 

For example, in the case of Lift, J is a two-element lattice 0 < 1, with 
A 0 = I, Ai = F and Z\ 0 <i = p. 

4 Generalized Semi-direct Products 

A pioneering instance of the applicative interface was the parser combinator 
library of Swierstra and Duponcheel [18], which we here rehearse in a greatly 
cut-down form. 

These parsers are applied to the output of lexical analysis. Given a type 
Symbol enumerating symbol types, parser input consists of a list of Tokens, 
recording the symbol type and its text: 

type Token = (Symbol, String) 
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For example, there might be a Symbol for numeric literals, in which case the 
corresponding String would record the text of the number. Parsers take a list 
of tokens and return cither an error string or a parsed value together with the 
unparsed remainder of the input: 

newtype Parser a = P ([Token] -> Either String (a, [Token])) 

This type is a monad (built by adding to an exception monad a state consisting 
of a list of tokens), and therefore also an applicative functor. Parsers can be built 
using primitives to peek at the next symbol, to move to the next token returning 
the string value of the token read, and to abort parsing reporting an error: 

nextSymbol : : Parser Symbol 
advance : : Parser String 
throwError : : String -> Parser a 

In order to construct recursive descent parsers corresponding to phrases of a 
grammar, one needs to keep track of whether a phrase can generate the empty 
string, and also the set of symbols that can begin a phrase (its first set). Swierstra 
and Duponcheel's idea was to define a type containing this information about a 
phrase, from which a deterministic parser for the phrase could be constructed: 

data Phrase a = Phrase (Maybe a) (Map Symbol (Parser a)) 

The two components are: 

— The type Maybe a indicates whether the phrase can generate the empty 
string, and if so provides a default output value. 

— The type Map Symbol (Parser a) records which symbols can start the 
phrase, and provides for each a corresponding deterministic parser. 

The Functor instance for this type follows from the structure of the type: 

instance Functor Phrase where 

fmap f (Phrase e t) = Phrase (fmap f e) (fmap (fmap f) t) 

The idea, then, is to build a value of this type for each phrase of the grammar, 
with the following conversion to a deterministic parser: 

parser : : Phrase a -> Parser a 
parser (Phrase e t) 
I null t = def 
I otherwise = do 

s <- nextSymbol 

f indWithDef ault def s t 

where 

def = case e of 

Just x -> return x 

Nothing -> throwError ("expected " ++ show (keys t)) 
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A parser for a single symbol, returning its corresponding text, is 

symbol : : Symbol -> Phrase String 

symbol s = Phrase Nothing (singleton s advance) 

Alternatives are easily built: 

(< I >) : : Phrase a -> Phrase a -> Phrase a 
Phrase el tl <|> Phrase e2 t2 = 

Phrase (el 'mplus' e2) (tl 'union 1 t2) 

In a realistic library, one would want to check that at most one of the alterna- 
tives could generate the empty string, and that the first sets were disjoint. The 
information in the Phrase type makes it possible to determine this check before 
parsing, but we omit this in our simplified presentation. 

Now the lax monoidal structure corresponds to the empty phrase and con- 
catenation of phrases. A phrase a/3 can generate the empty string only if both 
the constituent phrases can, but the emptiness information for a also determines 
whether the initial symbols of aj3 include those of j3 in addition to those of a: 

instance Monoidal Phrase where 
unit = Phrase unit empty 

mult (Phrase el tl) (~p2@(Phrase e2 t2)) = 
Phrase (mult el e2) (union tl' t2') 
where 

tl' = fmap ('mult' parser p2) tl 

t2' = maybe empty (\ x -> fmap (fmap ((,) x)) t2) el 

In Haskell, a tilde marks a pattern as lazy, meaning it is not matched until its 
components are used. It is used here so that Phrase values can be recursively 
defined, as long as one avoids left recursion. 

We might wonder whether this definition is an instance of a general con- 
struction. We note that the Phrase type is a pair, and the first components 
are combined using the lax monoidal operations on Maybe, independent of the 
second components. This is similar to a standard construction on monoids, the 
semi-direct product, which takes a pair of monoids (A, *, 1) and (A", +, 0) with 
an action (•) : A x X — > X, and defines a monoid on A x X, with binary operation 

(a, x) 0 (6, y) = (a * b, x + (a • y)) 

and identity (1, 0). For example Horner's Rule for the evaluation of a polynomial 
a n x n + • • • + a\x + do can be expressed as a fold of such an operation over the list 
[(x, do), {x, ai), . . . , (x, o„)], with the immediate consequence that the calculation 
can be performed in parallel (albeit with repeated calculation of the powers of 

We shall consider a generalization of the semi-direct product on lax monoidal 
functors, requiring 

— a lax monoidal functor (F, ©, u) : (A, 0, T) — > (B, x, 1) 
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— a functor G : A — > £> with a natural family of monoids ffi : GaxGa^Ga 
and 0 : 1 ->• G a. 

— an operation xi : G a x (F 6 x G 6) — )■ G (a © 6) distributing over G: 

0x<7 = 0 (1) 
(x © y) x q = (x x q) ffi (y x g) (2) 

— an operation x : (F a x G a) x G b — > G (a © 6) distributing over G: 

p k 0 = 0 (3) 
p x (x © y) = (p x x) © (p x y) (4) 



also satisfying 



(p k y) x r = p k (y x r) 



(5) 



Proposition 3. Given the above functors and operations, there is a lax monoidal 
functor (H,®h,uh) ■ (-4, ©,T) — > (23, x,l) defined by 

Ha = Fax Ga 
u H = (u, 0) 

(a, x) ®h (b, y) = {a® b, (x x (6, y)) © ((a, x) x y)) 
provided that x and x are left and right actions on G, i.e. 



Uh x z = z 
(p ®H q) X z = px (q X z) 

x x uh = x 
x x (q ® H r) = (x x q) x r 



(6) 
(7) 
(8) 
(9) 



Proof. It follows from their definitions that H is a functor and ®h a natural 
transformation. Next, we show that ur is the left and right identity of ®h- 



u H ®h (b, y) = (1 © b, (0 x (b, y)) © (u H x y)) definition of ® H , u H 
= (1 © b, 0 © y) equations (1) and (6) 

= (fe, y) monoid laws 



(a, x) ©# uh ~ (a® 1, (x x %) ffi ((a, x) k 0)) dehnition of ®h, uh 
= (a © 1, x ffi 0) equations (8) and (3) 

= (a, x) monoid laws 



Constructing Applicative Functors 15 



Finally, we must show that ®h is associative: 
{(a,x) ® H (6,2/)) ® H (c, z) 

= (a ® 6 © c, (((x x (6, j/)) © ((a, x) k y)) xi (c, z))ffi definition of ©# 

(((a,a;) ® H (6,2/)) * «)) 
= (a © 6 © c, ((x xi (6, j/)) xi (c, z)) © (((a, x) x y) xi (c, z))ffi equation (2) 

(((a, a;) ® H (6,2/)) x z)) 
= (a © 6 © c, (x xi ((6, 2/) ©h (c, z)))© (9), (5) and (7) 

((a, x) k (?/ x (c, z))) © ((a, x) x ((6, y) k z))) 
— (a ® b * c, (x x ((6, y) ©# (c, z)))ffi equation (4) 

((a,x) x (y xi (c,z)) © ((6,y) k z))) 
= (a, x) ® H ((6, y) ©jj (c, z)) definition of ©jj 

□ 

In particular, Proposition 3 identifies the properties we need to establish to 
demonstrate that Phrase is lax monoidal, and thus applicative. 



5 Existentials and Coends 

Many applicative functors are constructed using existential quantification, hiding 
a private representation type. We shall consider the corresponding categorical 
notion, called a coend. 

Abbott, Altenkirch and Ghani [1] consider containers of the form 

Lc = 3 m. K m — > c 



Here m is drawn from a set of shapes M. (a discrete category), the functor 
K : Ai — > C assigns to each shape a set of positions within containers of that 
shape, and the function provides a value for each of these positions. For example, 
the shape of a list is a natural number n giving its length, which K maps to the 
set of positions {0, 1, . . . , n — 1}, the indices of the list. 

There are several ways that we can extend container functors to obtain useful 
lax monoidal functors. 

If we let M. be the natural numbers plus an upper bound u>, and Kn = {i \ 
i < n}, then L represents finite and infinite lists. We can define lax monoidal 
operations: 

u = (uj, const T) 
(to, /) © (n, g) = (to n n, (f, g}) 

That is, u yields an infinite list, and © constructs a list of pairs, whose length is 
the smaller of the lengths of the arguments. We recognize this functor as another 
version of the ZipList functor defined in Section 3. More generally, if Ai has a 
monoidal structure that is a lower semi-lattice, and K (toi l~l 7712) C K mi, then 
the lax monoidal structure on L computes zips on containers. 
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A type comprising arrays of different dimensions can be represented using a 
shape functor K satisfying KT~1 and K (a © b) = K a x K b. Then we can 
define lax monoidal operations with with u constructing a scalar and © being 
cartesian product: 

u = (T, const ()) 
(m, /) © (n, 5) = (to © n, / x 5) 

We can approximate such multi-dimensional arrays using a Haskell existential 
type (specified by using the quantifier keyword f orall before the data construc- 
tor): 

data MultiArray a = f orall i. Ix i => MA (Array i a) 

instance Functor MultiArray where 
fmap f (MA a) = 

MA (array (bounds a) [(i, f e) I (i, e) <- assocs a]) 

The unit operation constructs a scalar, while mult forms the cartesian product 
of two arrays: 

instance Monoidal MultiArray where 

unit = MA (array ((), ()) [((), ())]) 
mult (MA xs) (MA ys) = 

MA (array ((lx, ly) , (hx, hy)) 

[((i, j), (x, y)) I (i, x) <- assocs xs, 
( j » y) <_ assocs ys] ) 

where 

(lx, hx) = bounds xs 
(ly, hy) = bounds ys 

We could extend multi-dimensional arrays by adding a distinguished position, 
i.e. a cursor within the container: 

Lc = 3m. K m x (Km — » c) 

When two arrays are combined with mult, their cursors are also paired to form 
a cursor on the product array. 

Another example arises in Elliott's analysis of fusion [6], where folds are 
reified using a type 

data FoldL b a = FoldL (a -> b -> a) a 

The type constructor FoldL is not a functor, because its argument a occurs 
in both the domain and range of function types. Wishing to apply functorial 
machinery to these reified folds, Elliott introduced a related type that could be 
defined as a functor: 

data WithCont z c = forall a. WC (z a) (a -> c) 
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instance Functor (WithCont z) where 
fmap g (WC z k) = WC z (g . k) 

Although FoldL is not a functor, it nevertheless has operations similar to unit 
and mult. These can be described using a type class similar to Monoidal, but 
without the Functor superclass: 

class Zip z where 
zunit : : z () 

zmult : : z a -> z b -> z (a, b) 

The above type constructor FoldL is an instance: 

instance Zip (FoldL b) where 
zunit = FoldL const () 
zmult (FoldL fl zl) (FoldL f2 z2) = 

FoldL (\ (x,y) b -> (fl x b, f2 y b)) (zl, z2) 

This class is sufficient to define WithCont as a lax monoidal functor: 

instance Zip z => Monoidal (WithCont z) where 
unit = WC zunit (const ()) 
mult (WC tl kl) (WC t2 k2) = 

WC (zmult tl t2) (\ (x,y) -> (kl x, k2 y) ) 

5.1 Left Kan Extensions 

We now consider the general case. Kan extensions are general constructions that 
have also found applications in programming. The right Kan has been used to 
construct generalized folds on nested types [10], to fuse types [7], and to construct 
a monad (the codensity monad) that can be used for program optimization [19, 
8] . The lax monoidal functors discussed above are instances of the other variety, 
the left Kan. 

Kan extensions have an elegant description at the level of functors. Given a 
functor K : M — > C, the left and right Kan extensions along K arc defined as 
the left and right adjoints of the higher-order functor (oK) that maps to each 
functor C — > A to a functor M — >• C [13]. That is, the left Kan extension a 
functor T : M. — > A along K is a functor L : C — > A with a universal natural 
transformation r\ : T -4 L o K: 



M 



K 




/ 



A 



For our purposes, it will be more convenient to use the standard pointwise 
construction of the left Kan extension as a coend, corresponding to existen- 
tial quantification in programming languages. For convenience, we assume that 
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the category A is cartesian closed, and that C is an ,4-category [11], i.e. that 
the "hom-sets" of C are objects of A, with identity and composition morphisms 
satisfying the usual laws. Using the more familiar notation 3 in place of the in- 
tegral sign favoured by category theorists, the left Kan extension of T : M — > A 
along K : A4 —¥ C is the functor L : C — > A defined by 

Lc — 3m. Tm x C (K m,c) 

The examples discussed above are instances of left Kan extensions: 

— In the container example, T is the constant functor mapping to 1, and the 
monoidal structure on M has T = to and with <g> as minimum. 

— In the example of arrays with cursors, T is identified with K. 

— In the WithCont example, M is the subcategory of isomorphisms of A. T 
can model any type constructor, as although type constructors (like FoldL 
above) need not be functorial, they still preserve isomorphisms. 

To state that L c is a coend is to say that there is an initial dinatural transfor- 
mation ui : Tm x C (Km,c) — > Lc. This dinaturality of uj is expressed by the 
equation 

u) (T hx,k) = uj (x, k o K h) 

That is, the existentially qualified type m is abstract: we can change the rep- 
resentation without affecting the constructed value. The natural transformation 
r] : T ^> L o K is defined as 

r/x = uj (x, id) 

Initiality of ui means that a natural transformation from L is uniquely determined 
by its action on terms of the internal language of the form ui (x, k). For example, 
we can define the action of L on arrows as 

Lf(uj (x,k)) =u(x,fok) 

In order to make L lax monoidal, we shall assume that the functor K : A4 — > C 
is a colax monoidal functor, or equivalently a lax monoidal functor M op — > C op . 
That is, there are natural transformations 

s : K (a ® M b) -> Ka® c Kb 
n : K T M -> T c 

such that the following diagrams commute: 

K (T <S> a) — s —f- KT ® K a K {a ® T) — ^ K a ® K T 



n®K a Kp 



V 

Xo< T(g)Ka Ka^ Ka(g)T 



K a®n 
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K (a <g> (b <g> c)) — ^ Ka®K{b®c) Ka ®l Ka®{Kb®Kc) 

Ka 

K{{a®b)®c) K (a <g> b) <g> K c (K a® Kb)® K c 

s s®K c 

In the special case where the monoidal structure on C is that of products, there is 
only one choice for n, namely the unique arrow KT — > 1. Moreover in that case 
s : K (a®b) ^ K ax K b can be broken down into two components: s = (si, s 2 )- 

Proposition 4. If At andC are monoidal and A has finite products , K is colax 
monoidal and T is lax monoidal, then L is lax monoidal, with 

u L =uj(u T ,n K ) 

LU (Xi,ki) ®L W (X2,k 2 ) = UJ (xi ©T X2, fcl X fc 2 O S^) 

This is a special case of Proposition 5, which we shall prove in the next 
section. 

A degenerate example has M. as the trivial category with one object and one 
morphism, so that T defines a monoid and K selects some object, with = id. 
This describes computations that write output and also read an environment, 
but in which the output is independent of the environment: 

Lc = Tx (K -> c) 

This applicative functor is a composition of two applicative functors that are 
also monads, but the composition is not a monad. 

Another simple case arises when Ai is a cartesian category, in which case an 
arbitrary functor K : M. —¥ C can be made colax monoidal by setting s, = K 7r,. 
Thus we obtain the following Haskell version of the left Kan: 2 

data Lan t k c = forall m. Lan (t m) (k m -> c) 

instance (Functor t, Functor k) => Functor (Lan t k) where 
fmap f (Lan x k) = Lan x (f . k) 

instance (Monoidal t, Functor k) => Monoidal (Lan t k) where 
unit = Lan unit (const ()) 
mult (Lan xl kl) (Lan x2 k2) = 
Lan (mult xl x2) 

(\ y -> (kl (fmap fst y) , k2 (fmap snd y))) 

Although this implementation has the form of a general left Kan extension, it is 
limited to the Haskell category. 

A richer example occurs in the modelling of behaviours of animations using 
applicative functors by Matlage and Gill [14]. The basic functor comprises a 
function over a closed interval of time, which can be modelled as pairs of times: 



2 In fact the Functor instance requires no assumptions about t and k, and in the 
Monoidal instance Zip t could replace Monoidal t. 
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data Interval = Between Time Time 

instance Monoid Interval where 
mempty = Between inf (-inf) 

Between start 1 stopl <> Between start2 stop2 = 

Between (min start 1 start2) (max stopl stop2) 

We would like to represent continuous behaviours by a type 3i. K i — > T, for a 
functor K mapping pairs of times to closed intervals of time, with Sj mapping 
from larger intervals to smaller by truncation. We cannot express this directly 
in Haskell, which lacks dependent types, but we can approximate it with a type 

data Behaviour a = B Interval (Time -> a) 

provided we hide the representation and provide only an accessor function: 

observe : : Behaviour a -> Time -> a 
observe (B (Between start stop) f) t = 
f (max start (min stop t)) 

Now this type can be made monoidal with the following definitions, which pre- 
serve the abstraction: 

instance Functor Behaviour where 
fmap f (B i g) = B i (f . g) 

instance Monoidal Behaviour where 
unit = B mempty (const ()) 
mult bl@(B il fl) b2@(B i2 f2) = 

B (il <> i2) (\ t -> (observe bl t, observe b2 t)) 

The final functor used by Matlage and Gill can be obtained by adding constant 
behaviour using Lift: 

type Active = Lift Behaviour 

Thus a value of type Active a is either constant or a function of time over a 
given interval. A combination of such behaviours is constant only if both the 
arguments were. 

5.2 The General Case 

Our final example is a generalization of the type used by Baars, Loh and Swier- 
stra [3] to construct parsers for permutations of phrases, which we express as 

data Perms p a = Choice (Maybe a) [Branch p a] 

data Branch p a = forall b. Branch (p b) (Perms p (b -> a)) 
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This implementation is too subtle to explain in full detain here, but the Perms 
type is essentially an efficient representation of a collection of all the permuta- 
tions of a set of elementary parsers (or actions, in other applications). The type 
in the original paper is equivalent to restricting our version of the Perms type to 
values of the forms Choice (Just x) [] and Choice Nothing bs, allowing a 
single elementary parser to be added to the collection at a time. In contrast, the 
mult methods allows the interleaving of arbitrary collections of actions, allowing 
us to build them in any order. 

The functor instances for these two types are straightforward: 

instance Functor p => Functor (Perms p) where 
fmap f (Choice def bs) = 

Choice (fmap f def) (map (fmap f) bs) 

instance Functor p => Functor (Branch p) where 

fmap f (Branch p perm) = Branch p (fmap (f . ) perm) 

Assuming that p is lax monoidal, we will construct instances for Perms p and 
Branch p. These types are mutually recursive, but we know that final fixed 
points preserve applicative functors. 
We define an operator *** as 

(***) : : Monoidal f => f (al -> bl) -> f (a2 -> b2) -> 

f ((al,a2) -> (bl,b2)) 
p *** q = f map (\ (f ,g) (x,y) -> (f x, g y)) (mult p q) 

This is an example of the construction of static arrows from applicative func- 
tors [15]. Now, assuming that Perms p is lax monoidal, we can construct an 
instance for Branch p as a generalized left Kan extension: 

instance Monoidal p => Monoidal (Branch p) where 
unit = Branch unit (pure id) 
mult (Branch pi perml) (Branch p2 perm2) = 
Branch (mult pi p2) (perml *** perm2) 

The instance for Perms p is constructed from the instance for Branch p as a 
generalized semi-direct product, which builds all the inter leavings of the two 
collections of permutations: 

instance Monoidal p => Monoidal (Perms p) where 
unit = Choice unit [] 

mult (tl(S(Choice dl bsl)) (t2@(Choice d2 bs2)) = 
Choice (mult dl d2) 

(map ('mult 1 include t2) bsl ++ 
map (include tl 'mult') bs2) 

where 

include : : Monoidal p => Perms p a -> Branch p a 
include p = Branch unit (fmap const p) 
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To encompass examples such as this, we need a generalization of the left Kan. 
Suppose the functor K factors through a monoidal category B: 



B 




We also assume a natural operator 

M : C(Ja,Jb) x C(Jc,Jd) -> C(J (a <g> c), J (b <g> d)) 

(corresponding to *** above) satisfying unit and associativity laws: 

JAo/KT = /oJA 
J poT® f = fo J p 
Jao f®(g®h) = (fMg)MhoJa 

The situation of ordinary left Kan extensions is the special case where J is the 
identity functor and is <8>c- However in general we do not require that be 
a functor. The key example of a structure with such an operator is an enriched 
premonoidal category, or "arrow" [2,9]. 

Proposition 5. If M. and B are monoidal, A has finite products, H is colax 
monoidal and T is lax monoidal, then F — L o J is lax monoidal, with 

Fa = 3m.Tmx (J(Hm)^Ja) 
Ff(uj {x,k))=w(x,Jfok) 
up = uj (ut, J nn) 
LJ (Xl,kl) ®pLO (x 2 ,k 2 ) — uj (xi ®t x 2 , fci Kl fc 2 o J s H ) 

Instead of proving this directly, we show that the functor G : M op x M x A 
defined by 

G(m',m,a) = T m x (J (H m') -+ J a) 

is itself lax monoidal, and then use a general result about coends of lax monoidal 
functors. To see that G is lax monoidal, we note that T is lax monoidal, so we 
only need to show that the second component is. The left identity case is 

FXoid^koJ {n H x 1 o sh) = k o J (A o ur x 1 o sr) left identity of 

= k o J (H A) left identity of H 

The right identity case is similar. Associativity relies on the associativity of E3: 

J a o k\ M (k 2 Kl fc 3 o J sh) ° J sh 

= J a o k\ M (k 2 M fc 3 ) o J [id x sh ° sh) naturality of M 
= {k\ M k 2 ) ks o J (a o id x sr 0 sr) associativity of Kl 

= (ki M k 2 ) M k 3 o J (s H x id o s H o H a) associativity of s H 
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Thus it suffices to show that coends preserve lax monoidal functors, which is our 
final result. 

Proposition 6. Given monoidal categories A and B and a ccc C, with a lax 
monoidal functor G : A op x A x B — > C, then the coend Fb = Ba.G (a, a, b) is 
also lax monoidal, with 

Fb = 3a.G(a,a,b) 
Ff(ux) = co{G{id,id,f)x) 

Up — UJUq 
LO X 1 ® F LU X 2 — CO (Xi ®G X 2 ) 

Proof. It is a standard result that a parameterized coend such as F defines a 
functor. Naturality of ®f follows from naturality of ®g- 

F(h ® fi) (wii ® f lox 2 ) 

= F (fi <X> f 2 ) (w (xi ®g x 2 )) definition of ©f 

= co{G {id, id, f\ (g> f 2 ) {x\ ®g x 2 )) definition of F 

= lo (G {id, id, fi) x\ ®g G {id, id, f 2 ) x 2 ) naturality of ®g 

= Lu {G {id, id, fi) xi) ® F co {G {id, id, f 2 ) x 2 ) definition of 

= F f\ {lo xi) ® f F f 2 (u x 2 ) definition of F 

Similarly the left identity law for F follows from the corresponding law for G: 

F A (up ®f lo x) = F X {lj uq ®f lj x) definition oi up 

= F A {lo {ug ®g x)) definition of ®p 

= co {G {id, id, A) {uq ®g x )) definition of F 

= uj{G {id, A o A -1 , A) {uq ®g x )) isomorphism 

= uj{G (A -1 , A, A) {ug ®g x)) dinaturality of co 

— cox left identity of G 

The right identity case is similar. 

Finally, the associativity law for ©^ follows from the associativity of ®g- 

F a {lo x ®p {coy ®f lo z)) 

— F ol{lo x ®p lo {y ®g z)) definition of ©f 

= F a {lo {x ®g {y ®g z ))) definition of ©f 

= co {G {id, id, a) {x ®g {y ®g z ))) definition of F 

= co {G {id, a o oT x , a) {x ®g {y ®g z ))) isomorphism 
= co {G (a -1 , a, a) {x ®g {y ®g z ))) dinaturality of lo 

= lo {{x ®g y) ®g z ) associativity of G 

= co {x ®g y) ®f lo z definition of ®p 

= {co x ®p lo y) ®p lo z definition of ©f 

□ 

As a further example, we have the coend encoding of the final fixed point 
i/F of a functor F : A x B ->• B: 

vFa = 3b.bx {b^F{a,b)) 
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which is a coend of G (&', b, a) = b x (U — > F (a, b)), and yields the same applica- 
tive functor as discussed in Section 3. 

6 Conclusion 

We have established a number of general constructions of lax monoidal func- 
tors, and therefore of applicative functors. In examples such as the permutation 
phrases of Section 5.2, we showed that by combining these constructions we could 
account for quite complex (and useful) applicative functors, avoiding the need for 
specific proofs of their laws. By breaking the functors down into simple building 
blocks, we have clarified their relationships, as well providing the tools to build 
more applications. The next stage is to examine the possible combinations, and 
to consider other constructions. 
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